Commodore Free 12/Commodore_Free_Issue_12_2007_Commodore_Computer_Club.d64/t.hex files 7

File List | 2023-02-26 | 8KB | 249 lines

u
Hexfiles Part 7
http://www.oldschool-gaming.com/
By Jason Kelk

Okay, so what happened last time?

Ah, yes I remember, I was going to
explain $D018 does, wasn't I?

Okay, well while I'm here I might as
well explain some of the rest of the
videochip at the same time. First off,
there are some conventions that we'll
use use here, the bits of a byte are
referred to as 0 for the lowest bit
through to for the highest.

Okay, so as promised lets start with
$D018, which is a pointer to where
the screen and character set are
stored. And before I go on, a little
lesson in architecture is needed. The
C64 has, as we know, 64K of memory but
the VIC-II chip isn't able to use it
all at once, instead it uses 1 of 4
"banks" of 16K, bank 0 is the lowest,
from the start of memory to $3FFF (and
the default, so for now we will keep
working in it) whilst bank 3 is the
last, at $C000 to $FFFF.

A C64 character set contains 256
characters, so with eight bytes per
character thats a total of 2K needed
and it's possible to point at any 2K
block in the present bank. Bits 1, 2
and 3 of $D018 control this, allowing
the VIC II to see any one of the eight
possible starting points for the
character data and setting the bits to
$0 will put the character set at $0000
using $2 will mean the font
is at $0800 all the way up (in steps
of two) until we get to $E, which
means $3800 has the font data.

Similarly, the C64 needs 1K for a
screen and bits 4 to 7 of $D018 are
used to represent where the screen is
living. Since there are 16 possible
screens in each bankading from, $0 will
put it down at $0000 and $F locates it
at $3C00. The actual default for $D018
is $14, the upper 4 bits are set to $1
so the screen is at $0400 & the lower 4
are $4 so the fifth character set in is
used, at $1000. The reason the C64
defaults like this is because a
"shadow" copy of the ROM character set
is stored at $1000 with the lower case
version at $1800.

A quick definition of shadowing is in
order, I think. The C64 only has 64K
of RAM but the ROM takes another 32K.
Because the 6510 can't access more
than 64K at any one time (it can only
look at $0000 to $FFFF) the ROM has to
exist within that space. But that would
take up valuable memory from programs.

So the ROMs are all shadowed over
other memory, the BASIC ROM is at
$A000 to $C000 and if you try reading
through that memory with the PEEK
command you'll be able to see it. But
it's *also* possible to store data
under that memory, for example
graphics, and not have the ROM
overwrite it and if we point the
VIC-II chip at it we don't see the
ROM data, just our graphics.

This means that we get all the ROMs
we need and *still* have the space
they occupy in the RAM, they're there
but in an insubstantial way, hence the
name ROM shadow. The character set at
$1000 works the other way around,if we
point the VIC-II at it we only see the
ROM font, no matter what data we put
there. But we can happily put data into
that RAM, read it out or run program
code from there without that font
affecting what we're doing (in fact,
$1000 is a very commonly used area of
memory for music routines for this
reason, a convenient 4K block for two
fonts that can't be used for graphics)

Another useful location is $D011 and
it has a number of uses, bits 0,
1 and  are used to set the vertical
smooth  scrolling and bit 3 controls
the scroll masks, when this bit isn't
set, the border extends into the
screen area slightly and masks hides
the edges of the screen so that the
new data coming on can't be seen until
it's ready. Bit  controls the screen,
if it's set the screen is on,otherwise
the border covers it. Turning the
screen off may seem a little pointless
but there are purposes, for example
hiding the screen until the graphics
have been set up.


Bit 5 of $D011 will activate bitmap
screen mode if set, instead of the
normal 256 character set the VIC chip
takes a block of 8,000 bytes, 8 for
each character square of the screen,so
really it's just like having a *very*
large character set. Bitmap mode has a
few disadvantages over normal screen
modes, it's memory consuming (a
bitmapped picture such as a loading
screen needs 10,000 bytes of memory
all told when the colour is added) and
it's difficult to scroll.
Not impossible, just difficult. The
*advantage* of bitmaps are that they
have more colours available to them.
I will be covering the basics of bit-
maps in more detail a little further on

$D016 has been covered before, we
used it in the Ferris demo to scroll
the message across the screen & smooth
scrolling is the job of bits 0 to 2,
along with bit 3 which controls the
masks at the sides of the screen in the
same way as $D011. Bit 4 is used to set
multicolour mode, one of those little
quirks of the C64's video system.

When multicolour mode is on the pixels
don't just appear as they are stored,
instead the bits are grouped together
in twos horizontally & the 2 bit number
they produce represents 1 of 4 colours.
This reduces the horizontal resolution
of the screen by half because each
character is now only four pixels wide
(physically they don't change size, but
the pixels are now twice as wide) but
we do have more colour control.

The character colour, in locations
$D800 onwards, is used to control
multicolour mode and, as we have done
before, when we set it normally we have
sixteen colours, values $00 to $0F. But
multicolour mode allows us to mix
standard characters and multicolour
ones because the first eight colours
(black, white, red, cyan, purple,
green, dark blue and yellow, values $00
to $07) will produce their normal eight
pixel wide characters but using colours
$08 to $0F produces those eight colours
again but in multicolour mode. So where
does the colour information for our two
new colours come from? $D022 and $D023
are the multicolour registers. They
function just like $D021 (the back-
ground colour) but only affect multi-
color areas on characters using colors
$08 to $0F.
Our four possible colours therefore
come from the character colour, $D021
for the background colour and the two
multicolours, giving four in total.

Bitmaps (and I said I'd get back to
them, didn't I?) work a little
differently. When we use bitmap mode,
the screen becomes the colour info for
the bitmap. So, if we set $D011 to $3B
to switch bitmap mode on and $D018 to
$18, we now have 1,000 "characters" on
the screen, each with it's own
individual colours.  The lower 4 bits
of the screen (in this example at
$0400) represent one of the colours &
the upper four a second, $00 will set
both to black and $FF will make them
light grey for example. But the most
interesting use for bitmaps is with
multicolour on, so we set $D016 to $18
and now we have lots of colours.

Why? Well, at $0400 to $07E7 we have
1,000 bytes of colour information, 2
colours per character. But in multi-
colour bitmap mode we *also* have the
$D800 colour map, as used by the screen
normally to give us a third colour and
the background for our forth. And the
$D800 colours are not limited to the
first seven as with multicolour
characters, they can be any colour from
$00 to $0F.

The only drawback to having this much
colour (three colours per character
square) is that there are some 10,000
bytes of data required, 8,000 for the
bitmap itself and 2,000 over two
areas for the colour data, so moving
it around is a no-no without some
trickery which we will have to leave
for a while yet.

Right, well thats the theory over with
& indeed the article, but next time
I'll be performing a more practical
demonstration of how bitmaps work with
some example code and a picture to play
with.

In the meantime, a small challenge
regarding $D018, can you work out what
the values would be to put the screen
at $3400 & the character data at $2800?
Work it out on paper & check yourself
against the start of the next part and
if you have any questions, suggestions
or whatever about this or C64 code in
general, contact me.

Commodore Free
would like to thank Jason for
allowing the reprinting of the
HEXFILES the article was taken from
http://www.oldschool-gaming.com/